Update rule grouping section #211
Conversation
|
Should we add |
| @@ -66,7 +66,9 @@ Accessibility Requirements {#structure-accessibility-requirements} | |||
|
|
|||
| An ACT Rule MUST identify the accessibility requirements to which the rule maps. For example, WCAG 2.0 Success Criterion 1.1.1. An ACT Rule is a complete or partial test for one or more accessibility requirements. | |||
|
|
|||
| Outcomes from an ACT Rule MUST be consistent with the accessibility requirement, e.g. a rule only returns the outcome Fail when the content fails the accessibility requirement. This means that the rule maps to the accessibility requirement, as opposed to it merely being related to the requirement, thematically or otherwise. | |||
| Outcomes from an ACT Rule that is not part of an [aggregation group](#grouping) MUST be consistent with the accessibility requirement, e.g. a rule only returns the outcome Fail when the content fails the accessibility requirement. This means that the rule maps to the accessibility requirement, as opposed to it merely being related to the requirement, thematically or otherwise. | |||
There was a problem hiding this comment.
"rule only returns the outcome Fail when the content fails the accessibility requirement" That's not correct. Rules can return fail, even if the requirement is passed. If only one rule in a group has to pass for the AR to pass, than any number of rules can fail without the AR failing.
There was a problem hiding this comment.
@WilcoFiers, This section is about "ACT Rule that is not part of an aggregation group". Next section is about "ACT Rules that are part of aggregation groups".
There was a problem hiding this comment.
"e.g. a rule only returns the outcome Fail when the content fails the accessibility requirement." --> "e.g. a rule not in a group only returns the outcome Fail when the content fails the accessibility requirement."
| Outcomes from an ACT Rule MUST be consistent with the accessibility requirement, e.g. a rule only returns the outcome Fail when the content fails the accessibility requirement. This means that the rule maps to the accessibility requirement, as opposed to it merely being related to the requirement, thematically or otherwise. | ||
| Outcomes from an ACT Rule that is not part of an [aggregation group](#grouping) MUST be consistent with the accessibility requirement, e.g. a rule only returns the outcome Fail when the content fails the accessibility requirement. This means that the rule maps to the accessibility requirement, as opposed to it merely being related to the requirement, thematically or otherwise. | ||
|
|
||
| For ACT Rules that are part of aggregation groups, the aggregated outcome of the aggregation group MUST be consistent with the accessibility requirement. For this to be possible, ACT Rules in an aggregation group MUST share at least one common accessibility requirement. |
There was a problem hiding this comment.
This seems to be repeating what is in the previous paragraph. I don't think this should say "aggregated outcome". It's just "the outcome of the aggregation group" is sufficient.
Question: Should the aggregation groups themselves be associated with accessibility requirements, rather than the rules within them?
| In accessibility testing, there are often multiple ways to solve the same problem. For instance, header cells in HTML tables can be indicated through the `scope` attribute, by using the `headers` attribute, or by using ARIA labels. All of these separate techniques could be described in one big rule. But this creates a large, and often difficult to maintain rule. To ensure rules are kept small and atomic, they SHOULD be put into a rule-group instead. | ||
| In accessibility testing, there are often different ways to make the same type of content accessible. These different techniques could be described in one big rule. This however creates large, and often difficult to maintain rules. | ||
|
|
||
| Rules are kept small and atomic. If there are multiple ways of passing the same accessibility requirement for the same content, these SHOULD be written as separate rules and be put into an aggregation group instead. A rule MAY be part of multiple aggregation groups. |
There was a problem hiding this comment.
Rules should be kept small and atomic.
| <li>Header indicated by using the `headers` attribute</li> | ||
| <li>Header indicated by using ARIA labels</li> | ||
| </ul> | ||
| <p>Aggregation logic for group: for a given test target to pass the group, any of the rules within the group must output a passed result for the test target.</p> |
There was a problem hiding this comment.
I would suggest "at leats one" instead of "any".
|
Closing this PR, as it is superseded by #217. |
@annethyme